ヘッダーをスキップ
Oracle TimesTen In-Memory Database Java開発者およびリファレンス・ガイド
リリース6.0
B25766-01
  目次へ
目次		 索引へ
索引
前へ
前へ 		次へ
次へ 		 

JMS/XLAの概念

Javaアプリケーションは、JMS/XLA APIを使用してTimesTenからイベント通知を受信できます。JMS/XLAは、JMSパブリッシュ・サブスクライブ・インタフェースを使用してXLA更新へのアクセスを提供します。

XLAへの接続を提供するJMS Sessionを確立して永続サブスクライバ（TopicSubscriber）を作成し、更新をサブスクライブします。このサブスクライバを使用してメッセージを同時に受信および処理したり、リスナー（MessageListener）を実装して非同期に更新を処理できます。

JMS/XLAは、ローカル・データ・ストアを監視するアプリケーション用に設計されています。TimesTenおよび通知を受信するアプリケーションは、同じマシン上に存在している必要があります。

注意: JMS/XLA APIでは、永続モードのXLAがサポートされています。このモードでは、XLAによって更新レコードがトランザクション・ログ・バッファまたはログ・ファイルから直接取得されるため、それらの更新レコードは読み取られるまで使用可能です。また、永続モードのXLAを使用すると、複数のリーダーでトランザクション・ログの更新に同時にアクセスできます。

XLAでレコードをトランザクション・ログから読み取る方法

アプリケーションによってTimesTenデータ・ストアが変更されると、TimesTenは、データ・ストアおよびトランザクション・コミットなどの他のイベントに対して行われた変更を示すログ・レコードを生成します。

生成される新しいログ・レコードは、常にログ・バッファの最後に書き込まれます。ディスク・ベースのロギングがデータ・ストアに対して有効になっている場合は、メモリー内のログ・バッファからディスク上のログ・ファイルに、ログ・レコードが定期的にバッチでフラッシュされます。

アプリケーションで、XLAを使用し、TimesTenデータ・ストアへの変更に関してトランザクション・ログを監視できます。XLAは、トランザクション・ログ全体を読み取り、ログ・レコードをフィルタ処理し、目的の表および列への変更が含まれているトランザクション・レコードのリストをXLAアプリケーションに配信します。

XLAは、レコードをディスクリート・トランザクションにソートします。複数のアプリケーションが同時にデータ・ストアを更新している場合、異なるアプリケーションのログ・レコードがログに交互配置されます。

XLAは、特定のトランザクションに関連するすべてのログ・レコードを透過的に抽出し、それらを連続するリストにしてアプリケーションに配信します。

コミット済のトランザクションのレコードのみが返されます。コミット済のレコードは、最後のコミット・レコードがトランザクション・ログに書き込まれる順序で返されます。コミットされていないデータ・ストアへの変更に関連するレコードは、XLAによってフィルタ処理されます。

変更が行われ、その後にロールバックされた場合、強制終了されたトランザクションのレコードはアプリケーションに配信されません。

これらのXLAの基本概念のほぼすべてを例3.1に示し、次にそれぞれの内容を箇条書きで示します。

例3.1

図3.1に示すトランザクション・ログを例として考えてみます。

図3.1
トランザクション・ログから抽出されるレコード

この例では、トランザクション・ログに次のレコードが含まれています。 

CT1 - Application C updates row 1 of table W with value 7.7 
BT1 - Application B updates row 3 of table X with value 2 
CT2 - Application C updates row 9 of table W with value 5.6 
BT2 - Application B updates row 2 of table Y with value XYZ 
AT1 - Application A updates row 1 of table Z with value 3 
AT2 - Application A updates row 3 of table Z with value 4 
BT3 - Application B commits its transaction 
AT3 - Application A rolls back its transaction 
CT3 - Application C commits its transaction 
 

表W、YおよびZへの変更を検出するように設定されているXLAアプリケーションでは次のようになります。


BT2 and BT3 - Update row 2 of table Y with value XYZ and commit 
CT1 - Update row 1 of table W with value 7.7 
CT2 and CT3 - Update row 9 of table W with value 5.6 and commit 
 

この例では、次のことが示されています。

XLAおよびマテリアライズド・ビュー

XLAを使用すると、表およびマテリアライズド・ビューの両方への変更を追跡できます。マテリアライズド・ビューによって、複数のディテール表内の選択した行および列への変更を追跡できる単一のソースが提供されます。マテリアライズド・ビューがない場合は、XLAアプリケーションで、すべてのディテール表の更新レコード（アプリケーションにとって重要ではない行および列への更新が反映されているレコードを含む）に対して監視およびフィルタ処理を行う必要があります。

一般に、表またはマテリアライズド・ビューへの変更を追跡するために使用するXLAメカニズムの間に処理上の違いはありません。

XLAトピック

XLAに接続するには、特定のデータ・ストアに対応するJMSトピックへの接続を確立します。構成ファイルjmsxla.xmlでは、トッピク名とデータ・ストア間のマッピングが提供されます。

jmsxla.xml内のトピック定義は、名前、JDBC接続文字列、および1回で取得する更新数を指定するプリフェッチ値で構成されています。また、アプリケーションがトピックに接続するときに、特定の表に対するXLAパブリッシングが自動的に有効になるように、enabledTables属性を含めることもできます。（これは、一連の静的な表を監視するアプリケーションで役立ちます。XLAパブリッシングを動的に有効にする方法の詳細は、「表への更新の監視」を参照してください。）

たとえば、例3.2に示す構成ファイルでは、DemoDataStoreトピックがTestDB DSNにマップされ、xyz.customer表の更新通知が有効になります。

例3.2 
<xlaconfig> 
  <topics> 
    <topic name="DemoDataStore" 
      connectionString="jdbc:timesten:direct:DSN=TestDB" 
      xlaPrefetch="100" 
      enabledTables="xyz.customer" 
    /> 
  </topics> 
</xlaconfig>

XLA更新

アプリケーションは、JMS MapMessageオブジェクトとしてXLA更新を受け取ります。MapMessageには、XLA更新ヘッダー内のフィールドに対応する一連の名前/値ペアが含まれています。

MapMessage取得メソッドを使用してメッセージ・フィールドにアクセスできます。getMapNamesメソッドは、メッセージ内のすべてのフィールドの名前を含むEnumerationを返します。名前ごとにメッセージから個々のフィールドを取得できます。予約されたすべてのフィールド名は、__TYPEのように2つのアンダースコアで始まります。

すべての更新メッセージには、メッセージに含まれている更新のタイプを示す__TYPEフィールドがあります。タイプは、整数値で指定されています。整数タイプと比較するために、com.timesten.dataserver.jmsxla.XlaContantsに定義されている定数を使用できます。表3.1に、サポートされているタイプを示します。

表3.1 XLA更新タイプ
更新タイプ
説明 
INSERT
行が追加されました。
 
UPDATE
行が変更されました。
 
DELETE
行が削除されました。
 
COMMIT_ONLY
トランザクションがコミットされました。
 
CREATE_TABLE
表が作成されました。
 
DROP_TABLE
表が削除されました。
 
CREATE_INDEX
索引が作成されました。
 
DROP_INDEX
索引が削除されました。
 
ADD_COLUMNS
新規の列が表に追加されました。
 
DROP_COLUMNS
列が表から削除されました。
 
CREATE_VIEW
マテリアライズド・ビューが作成されました。
 
DROP_VIEW
マテリアライズド・ビューが削除されました。
 
CREATE_SEQ
SEQUENCEが作成されました。
 
DROP_SEQ
SEQUENCEが削除されました。
 
TRUNCATE
表が切り捨てられ、表内のすべての行が削除されました。

XLA更新メッセージの内容の詳細は、「XLA MapMessageの内容」を参照してください。

XLAブックマーク

XLAブックマークは、トランザクション・ログ内のXLAサブスクライバ・アプリケーションの読取り位置にマークを付けます。ブックマークによって永続サブスクリプションが容易になり、アプリケーションはトピックから切断した後、読取りを中断した時点から、更新の受信を継続するために再接続できます。

XLAのメッセージ・コンシューマを作成する場合は、永続TopicSubscriberを使用します。サブスクライバを作成するときに指定するサブスクリプション識別子は、XLAブックマーク名として使用されます。表に対するXLAパブリッシングを開始および停止するためにJDBCを介して組込みプロシージャttXlaSubscribeおよびttXlaUnsubscribeを使用する場合は、使用するブックマークの名前を明示的に指定します。

応答を受信すると、ブックマークは最終読取り位置にリセットされます。更新メッセージが確認される方法の詳細は、「XLA応答モード」を参照してください。

JMS Sessionでサブスクライブ解除をコールすることによって、永続サブスクリプションを削除できます。これにより、対応するXLAブックマークが削除され、再接続するときに新規のサブスクリプションが強制的に作成されます。詳細は、「ブックマークの削除」を参照してください。

XLA応答モード

XLAの応答メカニズムは、アプリケーションがメッセージを受信するだけでなく、メッセージを正常に処理できるように設計されています。永続的に更新に応答すると、アプリケーションのXLAブックマークは、読み取られた最終レコードにリセットされます。これにより、以前に返されたレコードが再度読み取られることを回避できます。また、アプリケーションがXLAに再接続したときにブックマークが再利用された場合、以前に応答されたレコードをアプリケーションが受信しないようにすることもできます。

JMS/XLAは、XLA更新メッセージに自動的に応答します。また、アプリケーションは、応答するメッセージを明示的に選択できます。Sessionを作成したときに、更新の応答方法を指定します。

JMS/XLAでは、次の3つの応答方法がサポートされています。

更新のプリフェッチ

複数の更新レコードを一度にプリフェッチする処理は、XLAから各更新レコードを個々に取得する処理より効率的です。AUTO_ACKNOWLEDGEモードを使用すると、更新がプリフェッチされないため、他のモードよりも時間がかかります。可能な場合は、更新を重複して行うことができるようにアプリケーションを設計してください。これによって、DUPS_OK_ACKNOWLEDGEの使用、または更新の明示的な確認が可能になります。各メッセージが個々に確認されないようにすることができる場合、明示的に更新を確認すると、最も高いパフォーマンスを得ることができます。

更新の確認

XLA更新を明示的に確認するには、更新メッセージに対する確認をコールします。メッセージを暗黙的に確認すると、以前のすべてのメッセージが確認されます。通常は、確認と確認の間に、複数の更新メッセージを受信および処理します。CLIENT_ACKNOWLEDGEモードを使用していて、永続サブスクリプションを将来再利用する場合は、終了する前に、確認をコールして最後に読み取られた位置にブックマークを再設定する必要があります。

  前へ
前へ 		次へ
次へ
  目次へ
目次		 索引へ
索引